NOTICE 


THIS DOCUMENT HAS BEEN REPRODUCED FROM 
MICROFICHE. ALTHOUGH IT IS RECOGNIZED THAT 
CERTAIN PORTIONS ARE ILLEGIBLE, IT IS BEING RELEASED 
IN THE INTEREST OF MAKING AVAILABLE AS MUCH 
INFORMATION AS POSSIBLE 



I 



. » 


(NASA-Ch-1 6348 0) RKAL-Tiriii oKJTiiH 

tOd A ilULTI-LASER/MULH-DL'icicrOR oifSIiiil 
{u^Qi^eictcL Po j.ytfcch liic luot., Ti jy, u . Y.) 
120 p tie AOo/Mf A0 1 CSCL 2v)E 


N 80- 3072o 


Uaclas 






UJ/30 26477 


- 0 




.. r 








/ 


•/-. 


. V 






V <);./ 

Rens^laer : Pdlytechnic Institute 

' ' ' • It' \ tv » .... * 




Li 


■ . • .• V "N, ■ .; -• • 


‘/;r ' ' 

^ • Troy, New York 12181 

Cj • • - • .* 


■ ^ 






' . *>»■ 


•iT^ 


•fe 


• ■• o • 




, -£ 


■'C 






L 


o: 




RPI TECHNICAL REPORT MP-65 


REAL-TIME OPERATING SYSTEM FOR A 
MULTI -LASER/MULTI -DETECTOR SYSTEM 

by 

Gary Coles 


A Study Supported by the 
National Aeronautics and Space Administration 
Grant NSG-7369 


School of Engineering 
Rensselaer Polytechnic Institute 
Troy, New York 


July 1980 


I 

1 

I 

1 

! 


CONTENTS 

page 


LIST OF TABLES v 

LIST OF FIGURES vl 

ABSTRACT vii 

1. INTP.ODOCTION 1 


7- 2. THE RPI MARS ROVER 3 

T 

* A. Rover Description 3 

B. The One Laser-One Detector System 5 

j C. The Varlan-Idllom System 10 

» D. Realtime Software 11 

E. Results 13 

1 

; 3. THE ELEVATION SCANNING SYSTEM 15 


r A. General Description 15 

] B. The Prime Computer System 19 

C. The New Rover Interface 21 

D. The Dynamic Test Platform 26 

' 4. REALTIME SUPPORT SOFTWARE 28 

I A. Software Overview 28 

• B. Lower Level Routines 33 

r 1. DEVEIO 33 

. 2. MRVDIM 34 

3. TSROVR 36 

I C. System Routines 38 

1. EXEC 38 

2. NAVIG 51 

’ 3. BUFRES 55 

4. GETTOK 55 

J* 5. GETCMD 58 

I 6. CNVPAR 59 

7. KEYBIN 59 

? 8. SCREEN 60 

J 9. MAP 61 

10. CURSOR 61 

J 5. CONCLUSION 63 

A. Summary 63 

I 3. r ature Work 64 


] page blank not filmed 


ill 






pag« 

LITERATURE CITED 65 

APPENDIX A: Azimuth Data Word Formats 66 


APPENDIX B: Support Software Flowcharts 


71 


LIST OF TABLES 

page 

Table la,b RVRCOM 41,42 

Table 2 Hars . Default 43 

Table 3 Interaction Processor Connoands 43 

Table 4 Post-Processor Information Record 47 

Table 3 Keyboard Processor Commands 30 

Table 6 Azimuth Buffer Format 52 

Table 7 Navigation Formulas 54 

Table 8 a, b Post-Processor General Record 56,57 


LIST OF FIGURES 

Page 

Figure I. Rensselaer Mars Rover. ................................. 4 

Figure 2. One Laser-One Detector System....... 6 

Figure 3. Laser Trlangulatlon Concept 7 

Figure 4. Laser Azimuths..... 8 

Figure 5. Laser Data 9 

Figure 6. Elevation Scanning Concept 16 

Figure 7. ML-MD Trlangulatlon Concept 18 

Figure 8. Multidetector Data 20 

Figure 9. Realtime Interface 24 

Figure 10. Temporary Interface 25 

Figure 11. Dynamic Test Platform 27 

Figure 12. Realtime Hardware-Software Interface 29 

Figure 13. SCAN Timing 30 

Figure 14. Realtime System Flow 32 

Figure 13. Flow Diagram of EXEC.. 40 

Figure 16. Rimtlme Display 48 


vi 


ABSTRACT 


The first hazard detection system uaed on the Rensselaer Mars 
rover was the one laser-one detector system. This system Is reviewed 
briefly with respect to the hardware and software subsystems, the opera- 
tion, and the results obtained. 

Recently, a multldetector scanning system nas been designed 
to Improve on the original system. Interactive support software has 
been designed and programmed to Implement real time control of the 
rover or platform with the new elevation scanning mast. The formats of 
both the raw data and the post-run data files have been selected. In 
addition, the Interface requlrem^ts have been selected, and some 
initial hardware-software testing has been completed. 
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INTRODUCTION 

Our knowledge o£ Che solar system has increased dramaclcally 
over Che past decade as our mode o£ planetary exploration has ap- 
proached Che planet surface. The rate of new discoveries has acceler- 
ated la the progression from Sarth— based observation to orbital or fly- 
by missions, to landers, and finally to the ultimate manned missions. 

As these missions extend farther from Earth, It becomes prohibitively 
expensive to send up a manned mission. One possible alternative Is 
some type of unmanned autonomous rover tdilch has the capability to 
cover a great distance over the planet's surface. In this way It could 
visit a number of interesting scientific sites over an extended period 
of time. 

An Important part of such a rover is its path selection and 
hazard avoidance control system. Due to a large communication delay 
time between Earth and any other planet (except possibly the Moon) , 
Earth-based control other than on the macro level would be out of the 
question. Therefore the vehicle control system would have to be self- 
contained and highly reliable. 

The Mars rover group at Rensselaer has been trying to develop 
such a vehicular control system. These studies Include simulation and 
more recently, real time control on a prototpye rover. 

Results indicate that such a path selection system should be 
broken down into two to four distinct levels. Long-range goals could 
be planned to about the kilometer range using photographs from either 
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Earth or satalllta observatloa. Medium range paths in the tens of 
meters could be selected onboard the rover using some kind of range- 
finder or television Interpretation technique. Finally some kind of 
short-range technique must be used within about three meters of the 
vehicle to detect all hazards too small to be resolved In the longer 
range planning. 

This report will dlsctiss the organization and design of the 
real time support software used to Implement the short-range path 
selection system on the Rensselaer Mars rover. Besides implementing 
real time control, this software provides for easy program development. 
Programs developed on the simulator can be run under real time control 
xd.th only minor modifications. Also, all the raw data provided by 
the rover is saved for post-run analysis. 
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THE RFl MARS ROVER 
A. Rovt Dascrlptlon 

A 0.5 scale procotypa Mars rover was constructed at Ransaa- 
laar to test hardvara faaturas and raaltlaa control software (saa 
Figure 1). A short range hazard detection system has been implemented 
CO enable closed loop realtime path selection testing. Note that 
another group at RPI is working on medium range path selection cechni- 
ques using simulation. 

The payload of Che rover consists of a heading gyro, a pitch- 
roll gyro, an electronics section, and three automobile batteries used 
to power the motors and electronics. The electronics section Includes 
the telemetry transmitter, the speed and turning controller, the scan- 
ning mast controller, and the data acquisition and telemetry con- 
troller. On this system, the pitch-roll gyro was not used. 

The front axle of the rover is rigid and pivots directly 
under the mast. There are currently 15 steering positions from -90* to 
■t-90* In 12.86* increments. The immediate steering angle is read from a 
linear potentiometer connected between the frame and axle. Besides 
pivoting about a vertical axis, the front axle can also pivot about a 
heading or roll axis. This front axle roll angle is also read from a 
linear potentiometer, but it is not used in this system. 

The drive system of the rover consists of four motors, one 
on each wheel. Each motor has a tachometer connected to it to obtain 
wheel speed data. Steering the rover is accomplished by changing the 
speed of the four wheels such that a smooth turn is achieved while 
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aalntaintng approxioacaly constant valocity. Thara ara also two mctors 
which allow tba front and raar wheel struts to be raised or lowered. 
This gives the ability to ralsa or lower the payload, but it is not 
used during realtlae control. 

B. The One Laser»One Detector System 

The Rensselaer Mars rover uses a laser triangulation scheiue 
for its short range hazard detection system (see Figure 2). The laser 
Is a solid state GaAa laser diode which has ten watts peak power out- 
put at 904 nanometers* The beam is collimated and directed straight up 
the mast. A mirror is mounted on top or the mast and directs the beam 
at an adjustable angle toward the ground. A silicon PIN diode is used 
as a receiver. It is mounted part way up the mast and focused in a 
known cone of view toward the ground. The beam and detector cone arc 
adjusted to intersect at ground level such that the beam will be de- 
tected when falling on terrain between about ^30 cm from level (see 
Figure 3). this intersection is adjustable and is typically sec at 
1.5 meters from the mast axis. 

The entire mast Chen oscillates back and forth scanning a 
140* field of view. During each sweep Che laser fires at 13 azimuth 
angles, one per 10* increment, and centered on the steering heading 
(see Figure 4). 

The laser data is composed of one 15 bit word per scan, one 
bit per azimuth angle (see Figvre 5). The information provided by each 
bit is of a go - no go nature where a one or "good" return specifies a 
safe azimuth, while a 0 or "bad" return specifies a possible hazardous 
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C. The Varlan-Idllom System 

A Varlan 6201 mlnlcoaputer is used co control the rover. It 
is a 16 bit computer with 32K words of core memory. Included In this 
system Is a Tektronix terminal, a 10 megabyte cartridge disk drive, 
two 800 bpl tape drives and an Idllom graphics display. The Varlan Is 
of the 1960*3 era and therefore does not have virtual mapping or hard- 
ware floating point. There are three main registers: the A register, 

used as a general accumulater, Che 6 register, used for Indexing and 
as an extension of the A register for certain operations, and the X 
register, used for indexing. As an example of performance, a 16 bit 
by 16 bit multiply with one operand in register takes between 18 and 
20 usee. 

The disk memory unit is used to store off-line programs; no 
runcir.e overlays are used. Raw data Is saved on one of the magnetic 
tape units for post run analysis and the Idllom terminal is used to 
display Important runtime parameters as well as a map of the current 
rover position. The Idllom also provides a 60 Hz realtime clock in- 
terrupt which Is used for timing. 

The rover is linked to the Varlan by a two-way telemetry 
transmitter. A receiver at the Varlan side performs error correction 
and Chen inserts the data Intj temory using DMA (Direct Memory Addres- 
sing) . The data is always put in Che same Cable and each new value 
always overwrites the last respective value. In this way, the most re- 
cent value of any desired data word is always found in the same re- 
spective location. The maitimum rate for DMA is 202,000 words per 


second . 
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A cotmand to be sent to the rover from the computer is one 
word long. An OTA (output from A register) instruction is used to give 
this data to the Varlan Interface which then sends the comniand. 

Another communications link to the rover is the remote con- 
trol box. This box disables and overrides the computer control, and is 
used to provide manual control of the vehicle. It is useful in posi- 
tionii 3 the rover and for gaining emergency control. 

D. Realtime Software 

The only langtiage currently available on the Varlan computer 
is assembler and therefore all of the realtime programs are written in 
assembly language. Also, although previous descriptions of this soft- 
ware mention the use of external interrupts, they were not used due to 
hardware problems. 

The main object of the realtime software is path selection. 
Hazards must be identified and avoided, and the entire system state 
must be saved for later analysis. Most of the programs developed 
earlier for this system (see Reference 1) were left intact except for a 
few modifications. The major changes were in the path selection rou- 
tine as expected. 

The first workable idea to be implemented for realtime test- 
ing was termed "path-blocking," conceived earlier by M. Krajewski (see 
Reference 2) . Path-blocking involved the buffering of bad bits (hazards) 
in the laser data word. Specifically, four bits on both sides of any 
bad bit in the laser data word were set bad to buffer any obstacles. A 
clear path consisted of any four contiguous good bits. The clear path 
closest to the desired heading became the steering angle. If a clear 
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path could not be found then the rover would scan all possible steer- 
ing angles by turning Its front axle, and thus Its center of scan, to 
-70* and back to ■^70* looking for a clear path. If one could not be 
found then the rover would halt because back-up capability, although 
used In simulation, was not Implemented. 

To remember obstacles behind the line of sight, a laser data 
memory queue was used. This flrst-ln flrst-out queue was of variable 
length, and new entries were shifted left or right according to the 
steering angle. All of the elements were logically "anded" together 
with the newest scan before looking for a clear path. 

This early technique worked but it proved to have some flaws. 
Although it was able to keep the front wheels clear, the back wheels 
frequently clipped the obstacles on passing. This could be improved 
by increasing the length of the laser memory or increasing the width 
of the path-blocking buffer to five bits. Unfortunately, both of these 
solutions tended to make the overall system very conservative. It was 
determined that path-blocking, although effective for the front wheels, 
was ineffective for the back wheels. 

The solution to this problem was a two part path selection 
system, one dealing with the front wheels, and another for the back 
wheels. This algorithm called track-and-tum (TRKIRN) was pioneered 
by T. Sadeghi and continued by P. Dunn (see Reference 3). 

Since path-blocking seemed to work, it was kept for the front 
wheels. The back wheels used a new technique based on the position of 
the obstacle and the geometry of the rover. Given the geometry of the 
rover, the possible rear wheel trajectories could be calculated for 
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any steering angle. Therefore, a formula was developed which used the 
position of the obstacle to yield the necessary steering angle. Fin'* 
ally this steering angle would have to be truncated to one of the pos- 
sible steering angles. The last step was to combine the front and 
rear wheel constraints and choose the desired steering angle. 

The obstacle memory for the TRKIRN system was more compli- 
cated than the previous memory. The path-blocking laser memory was re- 
tained for the front wheels. However, the back wheels formula re- 
quired the locations of the obstacles in the planet frame to be saved. 

Other realtime software Included routines to decode vehicle 
state data, to send commands to the rover, to keep crack of the vehicle 
position, to update the Idllom display, and to save the system state 
for later analysis (see Reference 4). Another program was written to 
nm off-line on the IBM 360 computer to analyze this saved runtime 
data. 

E. Results 

The results of the lab tests were very encouraging. The ro- 
ver was able to successfiilly maneuver through almost every ob- 
. Stacie pattern that was given to it. The few times it failed can be 
attributed to the inability of this simple path selection system to re- 
solve a tight situation as being passable. 

In the field tests, the real problems showed up as expected. 

A little bit of pitch and roll made Che system even more conservative. 

A larger but still passable pitch or roll was interpreted as being 
hazardous. All in all, Che system performed quite well. The 
rover almost always found its target although not cilways by the most 
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direcc rouce. 

Most o£ the inadequacies of the one laset'-one detector sys- 
tem can be traced to its inability to Interpret and adapt to terrain 
containing slopes. However, this system still has some usefulness. 

Not all ideas have been tried to reduce Its conservatism in the lab 
tests . 

Overall, the rover was plagued by many problems. Most of the 
mechanical problems were due to the fact that the rover was not de- 
signed for the weight load which it acquired over the past few years. 
This caused some gears, shafts and other structural members to fail 
without warning. The electrical system was plagued by a chronically 
bad wheel speed controller which caused the wheels to move at slightly 
different speeds and the front axle to oscillate. This put more stress 
on the rover's structure. Finally, the software always seemed to con- 
tain some hidden bugs characteristic of large programs written in 
assembly language. 


PART 3 


THE ELEVATION SCANNING SYSTEM 
A. G«iaral Description 

The aecessary solution to the pitch and roll problen of the 
one laser-one detector system Is to come up with some system \rtilch not 
only provides range data but also height data. This would provide the 
Ixiformatlon necessary to Interpret slopes. 

Since the trlangulatlon concept worked It was decided to go 
with a modification of the one laser-one detector system. This new 
system Is known as the multi-laser multi-detector scanning mast (see 
Figure 6 and Reference 5). The major components of the ML-MD system 
are the spinning mirror scanner, the detector array, and the controller 
electronics. 

It was necessary to build a new mast which could support the 
heavier weight of the new system components. This mast rotates counter- 
clockwise at a preselected rate, normally about 0.5 revolutions per 
second, and is electrically connected to the chassis by slip rings. 

With two seconds between every scan. It is not possible to Ignore any 
scans, thus limiting the realtime processing to under two seconds. 

A new laser diode was chosen which could meet the new speed 
and power requirements (see Reference 6). It has a 10 KHz maximum 
pulse rate and an output of 100 watts. New collimator optics were de- 
signed to take full advantage of the diode's output power. An eight- 
sided mirror with a motor and positional encoder is mounted on top of 
the mast. With this arrangement the laser beam can be deflected to the 
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ground at an alavaclon angle selected by the rotational angle of the 
mirror. This Is used to simulate multiple lasers firing at a number 
of preselected angles (see Figure 7). 

The multi-detector receiver Is composed of a linear array of 
photodiode elements. Currently two such devices are being examined 
for this use. One Is a 20 element photodiode chip and the other Is a 
1024 element charge-coupled photodiode shift register chip. The 20 
element chip receiver Is known to work* but has the disadvantage of a 
limited nund)er of receiver cones with non-alterable cone angles. On 
the ocher hand, the 1024 element chip has a greater resolution, and 
cone angles can be altered by assigning a different number of elements 
per receiver* Unfortunately the 1024 element chip has some noise and 
sensitivity problems which require more Investigation. One possible 
method to increase the resolution of the 20 element chip receiver Is 
to use two of them; however this creates problems In Che design of 
Che receiver optics. 

Since Che 20 element detector will probably be the first one 
used. It can be seen chat the cone angles and sizes will be fixed by 
Che optics selected. The laser elevation firing angles, however, are 
alterable and will be selected by a PROM (Programmable Read Only 
Memory) in Che controller. In addition, the number of shots fired per 
azimuth, the number of azimuths, and Che azimuth angles are also PROM 
selectable. At this time, the number of azimuths and the number of 
laser shots per azimuth must have a product less chan or equal to 1024 
(e.g., 16x64, 32x32 and 13x20). Ihu controller must also insert the 
proper flags (e.g., end of azimuth) Into the data stream to synchronize 



FIGURE 7. ML-MD Trlangulatlon Concept 
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ch« daca with tha scan. 

It is obvious Chat the alavacion scanning system carries a 
great deal more information than tha one lasar-ona detector systmn. 

Each laser data return is not a go • no go flag any more, it is a 
word specifying which receiver cone, if any, sensed the laser shot. 

Also, since the optics makes it possible for more than one receiver 
element to see Che shot, each laser data return word contains the up- 
permost and lowermost '.ones to sense each shot (see Figure 8). 

Besides the scanning system, ocher rover systems were up- 
graded. A new wheel-speed controller was designed which uses a Mo- 
torola M 6800 microprocessor to provide the reliability of digital 
control. A new teleaietry system was necessary because of the greater 
data rate required by Che new scanning system. And finally there were 
many modifications made to Che electrical and mechanical subsystems 
such as rewiring end wheel strengthening. 

B. The Prime Computer Svstem 

With the new scanning system, it was obvious that the Varian 
computer would not be able to perform realtime control very easily. 

The amount of raw data alone is about 1000 times more than before. 

Since the Varian would limit the complexity and precision of any new 
algorithms, it was r^iclded to look for an alternative. The Image Pro- 
cessing Lab's Prime 500 computer was chosen as the best alternative, 
the Prime 500 is a new machine delivered in January 1979. It is a 
minicomputer with 32 bit internal architecture, hardware floating point 
and a very powerful instruction set implemented in microcode. As an 
example of performance, a single precision floating point multiply 
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cakes about 4.0 ysec. 

Besides having 512K bytes of main memory, virtual mapping Is 
used to provide each user with up to 32 M bytes. The system Includes 
two 80 megabyte disk drives, a mag-tape drive, a Versatec printer- 
plotter, and a number of terminals of which one Is a dedicated opera- 
tor's console. The Prime operating system Is written for a timeshar- 
ing environment servicing up to 63 terminals. Software includes FOR- 
TRAN IV, BASIC, Prime assembler, and a very powerful filing system 
(see Reference 7) . 

The ability to use higher level languages provides the bene- 
fit of easy program development and debugging. An added benefit Is the 
direct compatablllty between programs developed for the simulator and 
for realtime. 

The Prime 500 will shortly be replaced by a Prime 750 which 
Is much faster. No instruction execution times are available as yet, 
but the Prime 750 includes a high-capacity cache memory, an instruc- 
tion prefetch unit and a high speed floating point unit. 

C. The New Rover Interface 

To communicate with the rover It became necessary to build a 
new computer Interface. Unfortunately, this was one of the things 
about the Prime that was most troublesome. What was to be a 
reasonably simple design task turned up some problems which are still 
as yet unsolved. 

For the hardware part of the interface, a general purpose 
interface board (GPIB) was purchased from Prime. The GPIB enables the 
use of programmed Input-output (PIO) , standard and vectored Interrupts, 
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and a sec of direct memory funcclons (DMX or DMA, DMC, DMT). DMA is 
direct memory access where the starting address and word count are kept 
In Che register sec. Up to eight DMA channels (total) are supported by 
Che computer. DMC Is very similar to DMA, and stands for direct memory 
channel. In this case the starting and ending addresses are stored In 
high speed memory, providing up to 2000 DMC channels. DMT Is direct 
memory transfer, where the data address and word count are maintained 
external to the computer. The address must be applied to the bus with 
Che data when requesting a DMT. This allows a random accessing of 
memory. In our case, DMT is preferred because the laser data returns 
will not be in any particular order. This is because the mast con- 
troller fires the laser as soon as the angular position of the mirror 
corresponds to one of the desired elevation angles. 

Initially, rather than wasting the time building and de- 
bugging the full-blown interface, it was decided to build a simple test 
interface. This would allow testing of both hardware and software con- 
cepts. The Interface would test PIO, a hardwired vectored interrupt, 
and a hardwired DMT. Initially, nothing worked. After talking with 
Prime for a while, it was found that our GPIB documentation was incom- 
plete, and in a few minor locations, incorrect. Eventually, after more 
testing, the board started to show signs of life. The PIO, interrupt 
and DMT all worked fine separately, but when a vectored interrupt was 
, alternated with a DMT, strange results occurred. The system would run 
for about 20 seconds and tnen crash. Using a program to display the 
data as it came in, bad data words could be seen every once in a while. 
As another symptom, whenever the disk was active (reading or writing) , 
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Che system would crash even faster. This dlsk-GPIB interaction seemed 
to imply some kind of priority problem, but little difference was ob- 
served as Che GPIB priority was changed through every level. The same 
result occurred when our GPIB was tested on a different Prime SOO, 
thus eliminating a hardware problem on our- particular computer. It 
is still not known whether the problem is in hardware or software and 
even Prime is unable to supply an explanation. 

It was decided to put our upper level realtime interface 
aside and work on a degraded Interface which would allow the input and 
storage of data for off-line processing. Once data is available for 
software testing, Che realtime interface testing can resume. 

For a description of Che upper level interface see Figure 9. 
Each telemetry data word received by the interface is composed of 16 
bits of information and 16 bits of address or identifier. The address 
also contains any mast interrupts such as end of scan or end of azi- 
muth. This 32 bit word is received in serial and converted to parallel. 
In Che upper level interface, a portion of the address will be con- 
catenated with a register containing an offset address into real memory. 
D^f^ will be used to put the data into memory. Finally there will be 
one vectored interrupt which uses a status register to identify various 
conditions such as mast interrupts, data overruns, or timeouts. 

The temporary degraded interface can be seen in Figure 10. 

DMC will be used to insert all 32 bits of the telemetry data word, and 
DMC will be followed by an interrupt. It will then be up to the inter- 
rupt service routine to decide vdiere to put Che data from the address 
and to strip the scan status from the address part of the data. The 
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FIGURE 10. Temporary Interface 




degraded incerface will not allow the realtime processing o£ data, but 
should enable the accumulation of up to about 20 scans of data for 
off-line post processing. 

D. The Dynamic Test Platform 

A dynamic test platform on which the elevation scanning mast 
can be mounted Is currently under construction (see Figure 11). The 
Idea Is to enable accurate in-house testing of the hardware and soft- 
ware responsible for hazard detection. 

The platform is motor driven such that the pitch and roll of 
the mast Is dynamically variable. Both pitch and roll are separately 
controlled and each has variable amplitude and rate. An attitude gyro 
is mounted on the platform to provide pitch and roll data to the com- 
puter. 

This platform is expected to aid a great deal in soZcvare 
testing since the actual laboratory scene can be accurately compared 
to the computer results. It should also help in the difficult job of 


calibrating Che optics. 




SEALTIME SUPPORT SOFTWARE 
A* Softwaf Overvltw 

The new reeltiae software has been written on the Prime 500 
minicomputer and Is Intended for the higher level Interface. Because 
of unsolved problems with the Interface it may become necessary to 
modify the software; however, the basic flow can be left intact. 

The objective of the realtime software is still to implement 
control of the new Mars rover and to record the raw data from either 
the rover or the platform (see Figure 12) . Most of the software is 
written in FORTRAN; though, some assembler was used. 

The basic data consists of an Interrupt status flag, laser 
data, and vehicle state data (see Figure 13). The possible Interrupt 
status flags Include: 

EOA: End of azimuth; the data consists of laser 

returns and vehicle state Information. 

EOS: End of scan; same data as EOA, but also 

signals that a full scan has been taken. 

VI: Vehicle Interrupt; the data consists of 

vehicle state Information only. 

Timeout: No Interrupts have been received for 

at least one second; It signals a possible 
hardware problem. 

Overrun: New data has written over old data be- 

fore old data was read; stop vehicle and 
wait for next EOS before accepting new data. 

Telemetry data will enter the Prime via DMT Into an azimuth 
buffer, one azimuth at a time, followed by the appropriate interrupt. 
Azimuths can be broken into two types: a laser azimuth and a vehicle 
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azlsMth. A l«8«r azimuth would occur on the froncsida of a scan and 
would be followed by an EOA or BOS. A vahlcle azimuth would occur on 
tha backside of a sesn and would be followed by a VI. Because the 
vehicle data is not needed as often on the backside of a scan (for 
navigation), the vehicle azimuths can occur less frequently. 

From the azlanith buffer, the data is moved to one of two scan 
buffers. Each scan buffer is large enough to hold an entire v can with 
Che azimuths scored sequentially. There are two of them to provide a 
double buffering scheme such that the software can be processing one 
scan while another Is arriving. 

A macro description of Che overall realtime system will now 
be given (see Figure 14). The main routine, called EXEC, is In charge 
of Che entire system flow. After the user gives the RUM command, the 
system Is initialized. The system Chen waits for an interrupt to sig- 
nal chat some data is available. After an interrupt, MAVIG is called 
to convert the data to a usable format and to perform navigation. If 
an EOA interrupt occurred, then the data Includes laser returns, and 
Che MODEL routine is called to analyze these returns. 

The terrain modeller analysis can be further broken down in- 
to inpach and crosspath. Inpath is along an azimuth and can be done 
for each azimuth as it arrives. Crosspath Is along the scan and can 
only be done after the EOS Interrupt occurs. If an EOS did occur, then 
after performing a crosspath analysis, the modeller would pass Its re- 
sults to the path selection routine (PSA). Using both current and past 
information, the PSA would select an optimal path and send the appro- 
priate Cum command to the rover. Finally the data would be saved for 



FIGURE 14. Realclaft System Flow 











th« pose-nn «n«lysia and cha procaaa would ba rapaacad. 

B. Lowat Laval Boutinaa 

Haay aodifieationa had to ba aada to cha ?rlsa oparacing aya- 
cam CO Implamanc caalclaa eoncrol of cha rovar. Thia waa fur char com- 
pllcacad by cha fact chat cha oparaciag ayacam waa nora auicad Co 
tlmaaharlxig rachar chan co raalclsa control. Tha Prtaa oparaclng aya- 
cam (PR2M0S) la vary eomplax and tharafora will not ba daacrlbad hara. 
Mora inforoaclon can ba found In cha Prlaa aanuala and liaclng (aaa 
Rafaranea 7). 

PfUMOS la a aultilavai. operating ayacam axiaclng in lavala 
IZ, 1X1, XV, and 7. Our oparaclng ayacam la a modlflad varalon of 
P&ZHOS V Rav 15.0.* Hoca that moving to a naw ravlalon may raqulra 
algnlficanc changaa. Spaea waa lafc la cha oparaclng ayacam for tha 
addition of naw ayacam procaaaaa by cha addition of two apara camplacaa: 
SPl and SP2. Wa cook ovar cha SP2 camplata chroughouc. Baaldaa choaa 
changaa, chraa rouclnaa ancompaaa tha major addlclona co tha oparaclng 
ayacam. Thaaa ara DEVEIO, MRVDIM and T$ROVR. Alao a naw common block, 
MRVCOM, waa added. Floweharta for all of tha raalclma aupporc rouclnaa 
can ba found In Appendix. B. 

B« 1. 

DEVEIO la a cwo argument ayacam aubrouClna, wriccan In aa- 

aamblar language, which aliowa FORTRAM programa to axacuca 1/0 Inacruc- 

clona. The firac argument la tha inacrucclon, function, and device 

coda while cha a«cond argument la an input or output if raqxiirad. Ic 

la called aa a FORTRAN function aubroutlna and returns true if auccasa' 

*Noca that ac tha time of this writing, our varalon of cha oparaclng 
ayacam la being updated to Rav. 16.0. 
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ful and falsa if uaaueeaaaful. 

B.2. MRVDIM 

Vaccorad intarrupca from tha GPIB iatarfaea go through lo- 
cation 141g. Tha Intttrupt sarvlea routlna will automatically dlaabla 
any further Iatarfaea latarrupea. It will than NOTIFY tha Intarrupt 
procaaa MRVDIM by tha uaa of tha 'I^VSEM aamaphort and rotum. 

A samaphora la a two word aofewara davlca usad to asynchro- 
nously start-up or schadula other processes. Tha first word is the 
samaphora count* and tha second vori is a poiatar to the wait list. 

Thera are two operations that can be performed on a samaphora by a 
user. A user can NOTIFY a particular samaphora* which just dacramants 
that samaphora count. Whan tha computer gats around to examining tha 
samaphores* if It finds any that are lass than or equal to zero, it 
takas tha highest priority process from that wait list and puts it on 
tha ready list. Tha highest priority process on tha ready list runs. 

A user can also WAIT on a samaphora, which incr aments tha count* and 
puts that process on tha wait list. Note that if a process does a 
WAIT* and tha count remains lass than or equal to zero, that process 
•stays on tha ready list. 

Initially tha MRVSEH samaphora starts out with a count of one, 
and MRVDIM on the wait list. When tha MRVDIM process is started, it 
disables any further DMX and inputs tha intarrupt status register. It 
than checks tha statiis for a hardware overrun condition. This could 
occur if Che MRVDIM process took coo long with the last sec of azimuth 
data, therefore losing some of the next azimuth data. On an OVERRUN, 
the stopped flag (RVSTOP) is checked. RVSTOP declares whether the 
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rover Is currently halted by the MRVDIM process for either a hardware 
or software overrun. A software overrun occurs when the user process 
is uot done with either scan buffer before MRVDIM receives more data. 

If RVSTOP Is set then Ignore the OVERRUN since the vehicle 
is already stopped. If RVSTOP Is not set^ then put a -2 In the current 
buffer status word to signal an OVERRUN and NOTIFY the MRVFUL sema- 
phore to st/ . c up the user process. Also^ set RVSTOP and send a HALT 
command to the vehicle. MRVDIM will now wait until the next EOS so It 
can re-synchronlze the scan. Finally, whether RVSTOP was set or not, 
re-enable DMX and interrupts and WAIT on MRVSEM. 

If there was no OVERRUN then checK the status for a TIMEOUT 
condition. This interface generated interrupt signals a lack of ex- 
ternal Interrupts for at least one second. On a TIMEOUT, put a -3 into 
the ctirrent buffer status word to signal TIMEOUT and again NOTIFY the 
MRVFUL semaphore. Then send a HALT command to Che rover and WAIT on 
MRVSEM. Note that by not re-enabllng interrupts the MRVDIM process 
cannot be restarted. 

When there is no OVERRUN or TIMEOUT, examine RVSTOP. If 
RVSTOP is set, then check the status for an EOS. If no EOS then ignrre 
the interrupt, re-enable DMX and Interrupts and WAIT oo MRVSEM. But If 
an EOS was received then try to re-synch the scan. Check to see If one 
of the scan buffers has been declared empty by the user process. If 
there Is no empty buffer, then do nothing except re-enable DMX and in- 
terrupts, and WAIT on MRVSEM for another EOS. If there is a free 
buffer, then restart the rover. Then set up the new buffer pointers 
and clear RVSTOP. Finally, re-enabl^. DMX and interrupts, and WAIT on 
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MRVSEM. 

If there was no OVERRUN or TIMEOUT , and RVSTOP was not set, 
then there Is some azimuth data to move. First get the current time 
(TIMNOW and VCLOK), accurate to 1/330 second, and store It In the 
last two words of the azlmutn buffer. Then move the azimuth buffer 
to the ctirrent scan buffer. Since boch buffers should be locked In 
memory (from being paged out), if a fault occurs on the data move in- 
struction (Zi:lVD) , the user process must have abnormally terminated 
execution. In this case send a HALT command to the rover and again 
WAIT on MRVSBl without re-enabllng Interrupts. This Is the system 
failsafe; if the user process terminates, the rover is automatically 
halted. 

If there was no fault, then the move was successful. In that 
case NOTIFY MRVFUL, update the pointer to the scan buffer and then 
check for an EOS. If no EOS then again re-enable DMX and Interrupts 
and WAIT on MRVSEM. But if an EOS was received, then put the positive 
azimuth count in the buffer status word to signal an EOS to the user. 

If the other scan buffer is empty then set up the pointers to load into 
it next. If it is not empty, then set RVSTOP and halt the rover. 
Finally, empty or not, re-enable DMX and interrupts and WAIT on 
MRVSEM. 

B.3. TSROVR 

T$R0VR is a system routine written to simplify and protect 
the user-system software interface. It is a five argument FORTRAN sub- 
routine, and has five basic functions. It allows the user to initial- 
ize the interface, to stop the interface, to send rover commands, to 
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empty a scan buffer, and to WAIT on MRVFUL. The first argument selects 
the function. Error-cheeking with appropriate messages safeguards 
against incorrect usage. 

T$ROVR first checks to see if the rover is assigned to 'the 

user. The rover has been made an assignable device, and as such must 

be assigned and unassigned using: 

ASSIGN ROVER 
ONASSIGN ROVER 

Next it makes sure that the first call to TSROVR is an Initialization in- 
struction. Then it jumps to the function selected by the first argument. 

Initialization is the most complicated function. First, the 
scan buffer addresses, arguments 4 and 5 are checked for valid ad- 
dresses. Then the azimuth buffer size and ntuiber, argiiments 2 and 3, 
are checked for validity. The azimuth buffer size is restricted to be 
between 1 and 1022, while the azimuth number must be between 1 and 256. 

a 

Now T$R0VR checks to see if this is the first initialization call. If 
so then the device status is checked using DEVEIO to see if the GPIB re- 
plies. If everything is satisfactory then MAPIO is called to map the 
1024 word DMX buffer into the MRVDIM azimuth buffer. Then LOCRFG is 
called to lock MRVDIM, the azimuth buffer and the two scan buffers into 
memory. Finally, using DEVEIO, DMX and Interrupts are enabled and an 
XNIT command is sent to the rover. The MRVFUL semaphore count is 
zeroed and T$R0VR returns. 

The stop fimction starts by looping until the RVSTOP flag is 
set signalling that the rover has been stopped. It then calls UMAPIO 
to unlock or free the two scan buffers. Using DEVEIO, it again sends 
the HALT command to the rover, disables DMX and Interrupts and then 
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T$ROVR returns. 

The coomand function calls DEVEIO to send a conmand to the 
rover. It also loops until it is successful and then returns. 

The empty function is used to declare a scan buffer empty 
and to switch to the other buffer. The second argument selects the 
buffer being emptied. Note that successive calls must alternate buf~ 
fers. Since an OVERRUN may have stopped the rover, the third argument 
may be used to specify i^at restart command, if any, should be given. 
RVFILL is a variable used to keep track of which buffer is currentlv 
being filled, and RVNEXI, the buffer to fill next. The MRVDIM process 
will fill the buffer selected by RVFILL, move RVNEXT Into RVFILL, and 
clear RVNEXT. If MRVDIM finds RVFILL equal to zero, then no buffers 
are empty and a software OVERRUN occurs. The empty function sets up 
RVFILL and RVNEXI. 

Last Is the WAIT function. It checks RVFILL to make sure at 
least one scan buffer is empty. It then does a WAIT on the MRVFUL 
semaphore. 

C. System Routines 

The system routines make up the user process and Include the 
realtime system executive and its subroutines. Two of these subrou- 
tines: the terrain modeller (MODEL) and the path selection routine 

(PSA) will not be discussed here. 

C.l. EXEC 

The tnain upper level routine Is the Mars system executive. 
This Is the user process which performs the realtime analysis and con- 
trol. EXEC basically controls the flow of the system, with the real 
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work done by subroutines (see Figure 15). All of the routines are 
linked together by the main common block RVRCOM (see Table 1). Once 
EXEC Is started, the user has Che ability to run as many realtime ex- 
periments as desired without restarting Che system. The user can 
change parameters, select different PSA and MODEL routines, <‘ind even 
run the rover manually from the keyboard. 

On starting the system, EXEC first tries to Initialize Che 
important runtime parameters with default values. To do this It 
ATTACHes to the MARS. DATA subUFD (sub-User File Directory) and makes 
Chat its home UFD. Thl:: Is done to keep all the runtime data files 
separate from any programs being developed, and to try to keep them all 
together. EXEC Chen cpens the MARS . DEF.AULT file and reads the default 
values. Keeping default values in a separate file rather chan in the 
EXEC program itself makes them easier to change and does not require a 
recompilation of EXEC. The parameters initialized and the file format 
is shown in an example copy of the MARS. DEFAULT file (see Table 2). 

Note also that new parameters can be added easily. 

EXEC displays the :)arameter values and then enters the inter- 
action processor. The interaction processor is just a segment of code 
which allows the user to enter commands. The prompt for the interac- 
tion processor is "CO:", and the command line syntax is: 

<C0MMAND><» or , or (blank) ><VALUE> 

Note that for some commands, the delimiter and value may not be re- 
quired. The value may be eitiier real or integer, and will be converted 
automatically if necessary. Also, if a required value is omitted, the 
process wJl ask for it. The possible commands are kept in the array 
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FIGURE 15. Flow Diagram of EXEC 
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COMMON /RVRCOM/ 
BUFA(2048) 
BUFB(2048) 
LBUFF(1024) 
UB0FF(1024) 
PITCH(64) 
R0LL(64) 
H£ADNG(64) 
AXR0LL(64) 
STEER(64) 
SPEED(64) 
DTIME(64) 
XLOC(64) 
YLOC(64) 
ZLOC(64) 
TIME 
DHEAD 
NUMAZL 
NOMAZV 
NUMLA2 
NUMSEN 


/* Realtime System Common 

/* Buffer for Raw Data 

!* Buffer for Raw Data 

!* Buffer of Lower Laser Data 

/* Buffer of Upper Laser Data 

/* Vehicle Pitch per Azimuth (Rads) 

/* Vehicle Roll per Azimuth (Rads) 

I* Vehicle Heading per Azimuth (Rads) 

/* Front Axle Roll per Azimuth (Rads) 

I* Steering Angle per Azimuth (Rads) 

/* Vehicle Speed per Azimuth (M/Sec) 

I* Delta Time between Azimuths (Sec) 

7* X Location of Vehicle (M) 

/* Y Location of Vehicle (M) 

/* 2 Location of Vehicle (M) 

/* Total Time Since Beginning of Run (Sec) 
/* Desired Heading (Rad) 

/* Number of Laser Azimuths per Scan 
/* Number of Vehicle Azimuths per Scan 
{* Number of Laser Shots per Azimuth 
/* Number of Sensors per Azimuth 


TABLE la 


RVRCOM 


XFINAL 

/* 

X Location of Target (M) 

YFINAL 

/* 

Y Location of Target (M) 

DELTXY 

/* 

Desired "Closeness" to Target (M) 

IMOD 

/* 

Version of MODELLER to Use 

IPSA 

/* 

Version of PSA to Use 

DSPTIM 

!* 

Time between Display Updates (Sec) 

NUMAZT 

/* 

Total Number of Azimuths per Scan 

SCAN 

1 * 

Current Scan Number 

A2MUTH 

1 * 

Current Azimuth Number 

MAPX 

/* 

Map X Axis Range (M) 

MAPY 

/* 

Map Y Axis Range (M) 

ORIGX 

/* 

Map X Origin 

ORIGY 

/* 

Map Y Origin 

MRVCMD 

/* 

Command Sent to Rover 

OVRRUN 

/* 

Buffer Overrun Flag 

TIMOUT 

/* 

Timeout Flag 

EGA 

/* 

End of Azimuth. Flag 

VI 

/* 

Vehicle Interrupt Flag 

EOS 

/* 

End of Scan Flag 

INIT 

1 * 

Initialization Flag 

RUN 

/* 

Run Flag 


TABLE lb. RVRCOM 


* MARS. DEFAULT File: A Saapl* 

16 NUMAZL: Munber of Laser Azlnuchs per Sean 

4 MUHAZV: Huaber of Vehicle Azimuths per Scan 

20 NUMLAZ: Number of Laser Shots per Azimuth 

20 NUMSEM: Number of Sensors per Azimuth 

10.0 XFINAL: Target X Coordinate 

10.0 YFINAL: Target Y Coordinate 

0.3 DELTXY : Desired "Closeness" to Target 

1 IMOD: MODELLER Version 

1 IPSA: PSA Version 

20.0 MAPX: Map X Axis Range 

20.0 MAPY: Map Y Axis Range 

0 ORIGX; Map X Origin 

0 ORIGY: Map Y Origin 

0.25 DSPTIM: Time between Display Updates 


TABLE 2. MARS. DEFAULT File 
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TBLl, ana provlda for aaay axpanslon (sac Tabla 3). 

Tha Intaraetion proeoaaor atarca by inputting up to 40 
eharactara froa tha kayboard Into tha array KBU7. A aubroutina, eallad 
GEITOK, stripa tha firat tokan froa tha cooaiand llna« which ahould ba 
tha conBand, and ratuma it in tha array IBUF. Anothar subroutina, 
GETCMD, than aaarchaa tha TBLl array for a match to IBDF. If thara la 
no aat^h chan tha aaaaaga 

ILLEGAL COMMASn) 

is output and tha processor goes back for another command. If a match 
is found Chen Che command number Is ratumad in tha variable CMD. Each 
command in TBLl is foUowad by a key which tells what kind of value, if 
any, should follow tha command. CMD is used to index into TBLl to gat 
this key, which is assigned to the variable KEY. If KEY equals zero 
then chare are no parameters and so EXEC jumps to execute chat comnand 
Cturough a computed GOTO, indexed by CMD. Otherwise GETTOK is called 
again to gat the parameter. If the parameter is missing, it is re- 
quested only once using the prompt: "FAR*". And if the user enters 

nothing, then the command is ignored. If there is a parameter then the 
subroutine CMVFAR is called to convert the parameter from ASCII to 
either integer or real as determined by KEY. If there is an error on 
the parameter conversion Chen the message 

ILLEGAL PARAMETER 

PAR- 
IS issued and Che user can cry again. Finally, EXEC jumps through a 
computed GOTO, indexed on CMD, to execute the conunand. Note that whan 
executing a command with a parameter, the parameter is always checked 


4S 


DISPLY 


Display defaulc ] 

parameter values 

PRIME 


Return 

CO PRIMOS 

e 

MUMAZL 

Rvalue) 

Change 

NUMAZL 

to 

^Value^ . 

NUMAZV 

Rvalue) 

Change 

NUMAZV 

CO 

^Value^ 

NUMLAZ 

^Valuc^ 

Change 

NUMLAZ 

to 

^Value^ . 

NUMSEN 

^Value^ 

Change 

NUMSEM 

to 

^Value^. 

XFINAL 

^Value^ 

Change 

XFINAL 

CO 

^Value^ . 

YFINAL 

^Value^ 

Change 

YFINAL 

to 

^Value^. 

DELTXY 

Rvalue) 

Change 

DELTXY 

CO 

^Value^ . 

IMOD 

^Value^ 

Change 

IMOD to 

< 

Value^ . 

IPSA 

^Value^ 

Change 

IPSA CO 

< 

Value^ . 

MAPX 

^Value^ 

Change 

MAPX to ^ 

Value^ . 

MAPY 

^Value^ 

Change 

MAPY to ^ 

Value^ . 

ORIGX 

Rvalue) 

Change 

ORIGX to 

^Value^ . 

ORIGY 

Rvalue) 

Change 

ORIGY to 

^Value^ . 

DSPTIM 

^Value^ 

Change 

DSPTIM 

CO 

1 ^Value^. 

GO 


Begin 

accepting 

realtime data. 


TABLE 3. Inceracclon Processor Commends 
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for volldlcy flrte. 

On A GO coaBAad* aU nACAASAt^ flAgt And eountort Ato 
laltlAllzAd firtc. To onAblo tht PSA And MODEL routtnoA to InltlAlizA 
thmaAlyAs (tlncA dlff ortne vAroloni any Axltt) , ehny ata CAllod with 
thA rATlAblA HflT AAt ttUA* NAZt* THROVE lA CAllAd CO lalCiAliZA ChA 
inCArfACA. A poAt-procAAAor filA 1a thAn opAnAd to hold thA runtlaA 
dAtA for thlA pArtleulAr run. Ench roAltlsM AxpArioAnt goto a now 
poAt-procAAAor filA with A unlquA nAniA of thA form 

M. MM / DD / YI .# MN 

wherA MM, DO, And Tt ata thA two digit roprAAontAtionA of tho curront 
aonth, dAy, And yoAr rAspACtlvely. NN is a two digit numk«r bAtvAsn 00 
and 99, starting at 00 and incrmAntlng for asch now run of that par» 
clcular day. Aftar opaning this fils, EXEC wrltas an Infomation 
record with the format shown In Tabla 4. 

Next, tho CRT scraan is sat up for tha runtime display (saa 
Figure 16). During the run, these paraaetArs will be updated periodi- 
cally. The STATUS varlAble will show the current interrupt type: EOA, 

EOS, VI, TIMEOUT, or OVERRUN. The COMMAND label will show the last 
coaDsand sent to the rover, and the TTY CO label will show the operator 
coaaand input during runtiae. 

The pre-run InltlaliZAtion concludes by calls to TSROVR to 
empty both scan buffers and a call to KAVIG to allow it to inltialiae 
Itself. Finally, EXEC does a WAIT call using TSROVR which begins the 
realtime execution phase of EXEC. 

On an Interrupt, the buffer result subroutine, 3UFRES, is 
called. BUFRES checks the reason for the interrupt, scores the raw 
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WORD 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11-12 

13-14 

15-16 

17 

18 

19-20 


CONTBHTS 

Record Length («20 words). 

Record Identifier (-1 ■ Informetion Record) 
Current Month (01 - 12). 

Current Dey (01 - 31). 

Current leer (00 - 99). 

Current Tine (24:00). 

MCMAZL: number of laser etlmuths. 

NUMAZV: number of vehicle szimuths. 

NUMLAZ: number of losers per azimuth. 
HUMSEM: number of sensors per azimuth. 
XFIMAL: target X coordinate. 

YFIMAL: target Y coordinate. 

DELTXY: desired "closeness” to target. 

IMOD: version of MODELLER used. 

IPSA: version of PSA used. 

DSPTIM: time between display updates. 


TABLE 4. Post-Processor Information Record 
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A******************************************!******* 
* * 
* * 
* * 
* * 
* * 
* * 
* * 
* * 


* * 

* * 

* * 

* * 

* * 

* * 

* 

« * 

************* ****** A****************************** 


TClEt 

HBAOIHG: 

niCB: 

BOU.: 

X LOC: 

T LOC: 

AX ROLL: 

SPEED: 

STEER: 

LASER: 

STATUS: 

COMMAllD: 

TTY CO: 


X RANGE: Y RANGE: 

X GRIG: Y ORIG: 


ncT.HE 16 


Runcla* Display 
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data, calls NAVIG, and updates the display by calling the subroutine 
SCREEN. If a TIMEOOT interrupt was received then the run Is halted 
and control returns to the interaction processor. Otherwise a segment 
of code called the keyboard processor Is entered. 

The keyboard processor allows the operator to enter coonnands 
during runtime. At runtime, the terminal Is automatically placed into 
half-duplex mode, so that nothing the operator types will show up on 
the screen. This Is necessary since the cursor Is flying all over the 
screen updating the map and the display parameters. The keyboard pro- 
cessor reads what is typed on the keyboard from an internal buffer, 
and displays It following the TTY CO label. 

A subroutine called KEYBIN reads and displays the keyboard 
Input. When It comes across a line-feed character. It sets the flag 
ENTER true, and returns the text in the array BUF. The keyboard pro- 
cessor then uses the subroutines GETTOR, GETCMD and CNVPAR just as in 
the interaction processor. A different command table, CMDTBL, Is used 
to contain the possible runtime commands (see Table 5) . Also because 


of limited space, an error is signalled by an asterisk as 


* TTY CO; 


An At character has the effect of erasing the current command. 

Note that after a GO cosmiand in the interaction processor. 


data will be accepted, stored, and decoded, but the rover will be in 
the manual mode. Therefore, the PSA and MODEL routines will be skipped 


until Che RUN command is given. 

Finally, if EXEC is in the autonomous control mode, the 
selected MODEL routine will be called. Then, if an EOS interrupt' was re- 
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RUlt 

STOP 

F (value) 



T (value) 


TABLE 5 


Begin auconomous control. 

Stop rover. 

Forward conmand where: 

F 1 Slow 

F 2 Medium 

F 3 Fast 

Reverse command where: 

R 1 Slow 

R 2 Medium 

R 3 Fast 

Turn command where: 

(^alue) can take on the values (-7 to +7) 
and refers to 1 of 15 absolute steering 
angles. 

T -7 90" Left turn 

TO 0® Turn 
T 7 90* Right turn 

Keyboard Processor Commands 
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calved, the selected PSA routine will be called. The PSA will send 
coomands to the rover through a TSROVR call and then the used scan 
buffer will be emptied by another TSROVR call. Whether an EOS was re- 
ceived or not, the aaimuth and scan counts (AZMDTH, SCAN) ^re updated 
and EXEC Jtimps back to do a TSROVR WAIT call on MRV70L again. 

C.2. NAVIG 

The NAVIG subroutine has the job of converting the raw data 
to a form which can be used by the other programs, as well as keeping 
track of navigation. The raw azimuth data format is shown In Table 6. 
The Individual word formats can be found in Appendix A. 

NAVIG Is a four argument subroutine called from the BUFRES 
subroutine. 

NAVIG (VBOF, LA2B0P, UPBUF, LOBUF) 

The argument VBUF Is the address of the start of the current vehicle 
data buffer located ^d.thin the scan buffer. LAZBUF Is the address of 
the start of the current laser data buffer, also located within the 
current starting addresses in the UBUFF and LBUFF arrays respectively. 
Those arrays hold the upper and lower receiver cone numbers for each 
laser shot. 

In the beginning of NAVIG, the routine checks the variable 
INIT, located In RVRCOM, to see If It should Initialize Itself. There 
are many variables to zero out since NAVIG uses a cumulative technique 
to perform navigation. If INIT is false, then NAVIG begins to decode 
the data. 

The time, in seconds, since the beginning of the run is com- 
puted and kept In the variable TINE. Note that the MODEL routine uses 
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WORD CONTENTS 


1 

Not 

used. 

2 

Raw 

Steering Angle. 

3 

Raw 

Left-Rear Tachometer Reading. 

4 

Raw 

Right-Rear Tachometer Reading. 

5 

Not 

used. 

6 

Not 

used. 

7 

Not 

used. 

8 

Not 

used. 

9 

Raw 

Front Axle Roll Angle. 

10 

Raw 

Roll Angle. 

11 

Raw 

Fitch Angle. 

12 

Not 

used. 

13 

Raw 

Right-Front Tachometer Reading 

14 

Not 

used. 

15 

Raw 

Left-Front Tachometer Reading. 

16 

Raw 

Heading Angle. 

17 

Raw 

Time (minutes). 

18 

Raw 

Time (330's of second). 


TABLE 6. Azimuth Buffer Format 
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a lot of Infornatloa on a par azimuth basis when it does a crosspath 
analysis. Therefore, an array, DTIME, la formed to contain the time 
between azimuths for each azimuth. 

Next the heading angle, in radians, is computed and scored 
in Che array HE&ONG, one entry per azimuth. It Is necessary to touch 
on Che matter of bad data. Since data transmitted from the vehicle 
might be lost because of Interference, It Is important to detect this 
error and to minimize Its damage. The solution Is to make the ln~ 
terrupc process, MRVDIM, pack the empty azimuth buffer with Impossible 
data. Luckily, an all ones pattern cannot appear In the current data 
chosen. To minimize the damage, NAVIG will substitute the last valid 
value of chat particular variable. It will also put an asterisk next 
to that label on the display screen. If the operator sees that a data 
word Is consistantly wrong, then he could scop the rover, since there 
might be a hardware problem. In the laser data, a missing return will 
be substituted for a bad data word and the number of bad laser data 
words will be displayed next to the LASER label on the screen. 

After the decoded heading angle has been saved, Che pitch, 
roll and front-axle roll are decoded and scored in the arrays FITCH, 
ROLL, and AXROLL respectively. The speed is calculated from the average 
of Che two front wheel tachometer readings, and scored in the array 
SPEED. Next, Che X, Y, and Z locations of the rover are calculated 
using Che formulas given in Table 7. They ace stored in the arrays 
XLOC, YLOC, and ZLOC respectively. 

Now NAVIG checks to see if it is processing a VI interrupt. 

If so, Chen ic returns because there is no laser data. If it is pro- 
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AVG(SPEED) - SPEED(K)^^^SPEED . eK . -U . 


BETA(K) - HEADSG(K) + STEER(K) 


BETA(K) + BETA(K-l) 

AVG(BETA) ■ ^ Q ^ ^ 


AVO (PITCH) - »tCH<K)^-^^PIICH(!(-l) . 


XLOC(K) » XLOC(K-l) + AVG (SPEED) COS (AVG (BETA) ) 


YLOC(K) » YLOC(K-l) + AVG (SPEED) SIN (AVG (BETA) ) 


2L0C(K) » ZLOC(K-l) + AVG(SPEED) SIN (AVG(PITCH) ) 


where VARIABLE (K) » Current value 
VARIABLE (K-1) - Last value 


TABLE 7. Navigation Formulas 
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cessing an EOA or EOS, then there Is laser data. The upper and lower 
receiver cone nunbers must be separated from each laser data word and 
scored in the arrays OPBUF and LOBOF respectively. Data errors are 
made Into silssixig returns, and a count Is kept In the variable LDERR. 
Finally NAVIG returns. 

C.3. BUFRES 

BUFSES Is a subroutine which determines the Interrupt status, 
saves the raw data, calls MVIG to perform conversions and navigation, 
and calls SCREEN to update the display. It has one argument, BUF, 

BUFRES (BUF) 

which is Che current scan buffer address. 

BUFRES first decodes the interrupt status from the first word 
of the current scan buffer and outputs It to the display next to the 
STATUS label. If a TIMEOUT or OVERRUN occurred, then chat Information 
Is written to Che post-processor file and BUFRES returns. On an EOA, 
EOS, or VI interrupt, a similar post-processor record Is written with 
the format given in Table 8. Next, Che starting addresses for the ve- 
hicle data and laser data within BUF, and the laser data destination 
within UBUFF and LBUFF are calculated, and used in the call to NAVIG. 
Finally Che subroutine SCREEN Is called Co update the CRT display. 

C.4. GETTOK 

GETTOR is a general purpose subroutine which will parse a 
command line, returning tokens on consecutive calls. The delimiters 
recognized Include a blank, a comma, and an equals sign. The Prime 
subroutine R0TK$$ also returns tokens but it uses a different set of 


WORD 

1 

2 


3 

4 

5 

6 

7 

8 
9 

10 

11 


COMTEMTS 
Record Length. 

Record Identifier where: 

■-1 ■ Information Record 

1 ■ EOA Record 

2 ■ VI Record 

3 ■ EOS Record 

4 « OVERRUN Record 

5 - TIMEOUT Record 

6 « MODELLER Record 

7 « ?SA Record 

Last command sent to rover. 

Current Scan Number. 

Current Azimuth Number. 

Not used. 

Raw Steering Angle. 

Raw Left-Rear Tachometer Reading. 
Raw Right-Rear Tachometer Reading. 
Not used. 

Not used. 


TABLE 8a. Post-Processor General Record 


WORD 

COWTEWTS 

12 

Mot 

used. 

13 

Mot 

used. 

14 

Raw 

Front Axle Roll Angle. 

15 

Raw 

Roll Angle. 

16 

Raw 

Pitch Angle. 

17 

Mot 

used. 

18 

Raw 

Right-Front Tachometer Reading. 

19 

Mot 

used. 

20 

Raw 

Left-Front Tachometer Reading. 

21 

Raw 

Heading Angle. 

22 

Raw 

Time (minutes). 

23 

Raw 

Time (330* s of second). 

2 4- up 

Raw 

Laser Data (If EOA or EOS). 


TABLE 8b. Post-Processor General flecord 
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d«llmlt«rs. 

Th«r« are six arguments to this subroutine. 

GETTOK (im, BUF, LEN, 1BUF» ILEN, NCRAR) 

IPTR Is the current position within the coannand line. BUF Is the comr 
line array, packed two characters per word, of length LEN 
characters. IBOF Is the returned token array, also packed two eharac* 
ters per word, with a maximum length of ILEN words. NCHAR is the nun* 
ber of characters In the retximed token. Any unused characters are 
packed with blanks. 

GETTOK starts by packing IBUF with blanks. It then searches 
BUF from the current position, IPTR, until the beginning of a token Is 
found (the first non-dellmlter) . Finally, It searches BUF for the next 
delimiter while updating IPTR and DCHAR, and moving each character Into 
IBUF. 

C.5. GETCMD 

GETCMD is a simple subroutine which searches a given command 
table for a match to an Input token. There are six arguments. 

GETCMD (TBL, LEN, WID, CMD, BUF, NCHAR) 

TBL Is the input command table of dimensions LEN and WID. CMD returns 
the index Into TBL of the command which matches the token In the array 
BUF. If no match is found then CMD Is set to zero. NCHAR Is the num> 
ber of noU'-blank characters in the array BUF. Note that WID Is one 
greater than the number of words In each command of TBL. This Is be- 
cause every command has a key which declares the type of parameters. 

If any, to expect. 


The subroutine compares a command in TBL with the token in 
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BUF on 4 word by word bMln* If it falls than it cries the next coa- 
aand* until finally either finding a match or axhatisclng the cable. 

C.6. CMVPAR 

CmVFAR Is a slapla subroutine which converts numerical tokens 
from ASCII to numerical values. There are six argusMncs. 

CHVFAR (BUF» HCHA&, KZT, IVAL, RVAL, lER) 

BUF Is the ntsBerlcal token in ASCII format of length NCHAR characters. 
The variable KEY which Is obtained from Che command cable, declares 
Che type of numerical value expected where: 

KEY • 0 No parameter 
KEY ■ 1 Integer 
KEY • 2 Real 

IVAL and RVAL are the variables \^lch return the integer or real value 
respectively* lER is the return code where: 

lER ■ 0 Normal return 
lER • 1 Invalid key 
lER • 2 Invalid token 

The subroutine uses FORTRAN DECODE statements to convert 
directly from ASCII to numerical form as required* 

C*7* KEYBIN 

KEY3IN is a subroutine which allows keyboard input during 
nmclme* There are three arguments. 

KEYBIN (KNUM, ENTER. IBUF) 

KNUM is Che current number of characters input from the keyboard* Run- 
time commands are kept short to save precious time and therefore KNUM 
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la lifflit«d to A maxiauB of 8. ENTER 1« a logical varlabla which ia 
aae crua when cha conoand haa baan ancarad* This ia dacatainad by 
finding a llna-faad characcar in tha kayboard buffar. Tha coanand 
ia ratuxnad in cha array IBU?* 

Tha aubroucina acarta by aaccing ENTER falaa and calling 
cha PriM aubroucina KZYB88. KEYB$$ racuma a ona if anything ia in 
Cha kayboard buffar. and a zaro ocharwiaa. If KEYB$$ racuma a zaro 
chan KEYBIN racuma. But, if ic racuma a ona, tha Pziaa aubroucina 
TIIN la callad ^Ich gaca a characcar from cha kayboard buffar. If 
KEYBIN flnda tha characcar chan ic will araaa cha array IBUF 
and Cha taxt after tha TTY CO label on Cha acrean. A llna-faad 
cauaaa ENTER Co ba aac crua. If cha characcar ia not an Ac or line- 
feed, Chen ic la acorai in IBUF, and ic ia output naxc to cha TTY CO 
label. Tha rouClna chan loopa back Co Cha KEYB$$ call to chack for 
any remaining charactara in cha buffar. 

C.8. SCREEN 

SCREEN ia a aubroucina which updacaa Cha valuaa on cha dla- 
play acrean. It alao calla cha aubroucina MAP which updaCea cha dla* 
play map. Thera are no aubroucina argumenca. 

Tha Ciaa bamaan diaplay updacaa, DSPTIM, la varlabla and 
can ba aac by cha operator. Thla la provided bacauaa diaplay updating 
takaa a fair amount of Clma. SCREEN atarta by dacarminlng vhachar 1C 
la time Co update Che diaplay or not. If It la, Chan SCREEN updacaa 
Cha Clma, heading, pitch, roll, front-axle roll, X and Y locaclona, 
apaed, acaerlng, laaar acacua, and laaC rover command. Tha laaar 
acacua la cha number of bad laaar data worda. If any, and cha laac 
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rov«r conmand is th« last cotnand tant to tha rovar, usually by tha 
PSA rouclaa. SCREEN also flags any bad valua obcainad froa cha rovas 
by putting an astarlak bafora tha raapactiva labal. SCREEN finally 
calls tha MAP subroutina and than raturns. 

C.9. ^ 

MAP Is a subroutina which updates tha display nap on tha CRT 
scraan. Tha nap displayed is a top view of tha rovar, or tha X-T 
plana. Tha X and Y ranges and origins are variables, and can be sat 
by cha operator* These variables are displayed beneath the nap for 
reference during cuntlae. The screen size of the map is 50 characters 
In width by 20 characters in height. Because of Che poor resolution, 
Che rover Is represented by a one digit nunber which Increaencs 
nodulo-9 every update. If the rovar stops or doubles back, the 
operator will still see the position by the changing number. Note 
Chat this map might be too crude to be of any use, but only experience 
will cell. 

MAP starts by quantizing the rover X and Y locations on ^cs 
limited grid. If Che location falls outside Che map range, then It Is 
not plotted. The CURSOR subroutine Is used to position Che cursor, 
and Che digit marker is output. Finally tha digit market Is updated 
and MAP returns* 

C.IO. CURSOR 

The CURSOR subroutine Is used to position the cursor on the 
CRT screen. Note Chat this routine will only work when using an ADM<>3 
terminal. CURSOR Is written In assembler because it Is used often In 
Che runtime display updating. There are three arguments:* 
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CURSOR (ROU, COLUMM, lER) 

ROW and COLUMN art tha daairad euraor location*, vhara tha uppar laft 
eornar la (1,1). IBR ia a logical taturn coda which ia txua on an 
arror. 

CURSOR firac chacka tha ROW and COLUMN warlablaa for 
validity, and than adda an offaat of 237^ to aach variabla. Tha 
variablaa ara than packad Into a aingla word with tha row in tha fir at 
byta and tha coluan In tha tacond byta. To position tha cursor ra» 
quiraa two worda. Tha firat is a spacial coda, 115675g, or an ascapa 
followad by an aquals. Tha sacond is tha packad row and coluan data 
word* Tha Prlaa subroutlna TNOUA Is callad to sand this data to tha 
tanalnal. Finally CURSOR sats lER falsa and ratums. 
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PART 5 
CONaUSION 
A. Suaanary 

the laser trlangulatlon method of hazard detection has been 
proven feasible by the results obtained dxirlng the one laser-one de> 
tector system testing. Complete obstacle avoidance was possible with 
this system at the cost of a slightly conservative path selection 
ability. This conservatism was very much apparent In a field environ- 
ment idilch included slopes. It was because of this inability of the 
one laser-one detector system to interpret slopes that the elevation 
scanning system evolved. 

Simulation studies indicate that the elevation scanning sys- 
tem does provide enough data for an accurate slope appraisal. Cur- 
rently, all rover systems are being modified to Implement this new 
hazard detection system. 

New realtime software has been written on a Prime minicom- 
puter. The hazard detection and obstacle avoidance software develop- 
ment work has been done using the simulator. However, the realtime 
support- software has only had some limited testing since none of the 
required hardware is working yet. 

This support software has been designed to provide the user 
with a simple interactive environment. The user can change and dis- 
play parameters, control the rover either manually or autonomously, 
and even run as many tests as desired without ever halting the pro- 
gram. Important runtime values are displayed and all raw data is 
saved for post-run analysis. 
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B. Future Work 

Once the problems with the Prime test interface are solved, 
it is important that the lower level realtime software be completely 
tested. After the test Interface is understood, the realtime inter- 
face can be designed and constructed. 

The first realtime laser data will come from the dynamic 
test platform. Initial testing should be done with a static platform. 
Only when it appears that the hazard detection software can accurately 
interpret any scene can the rover be tested under realtime control. 

Programs to analyze the post-run data should be developed 
immediately since they will be necessary when testing the hazard de- 
tection software. Running off-line, the post-processor routines can 
use computer graphics to help display data. 

Although first testing should use a dedicated processor, it 
may be possible to allow other users on the system during realtime 
testing. This would require that our operating system be kept up to 
date with the normal operating system and that it have a low probability 
of crashing the system. Also, although unlikely because of time con- 
straints, the possibility of realtime graphics should be investigated. 
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